add SECURITY.md file for responsible disclosure #168
Conversation
docs: add SECURITY.md file for responsible disclosure
Create SECURITY.md
WalkthroughAdds a new SECURITY.md that defines supported versions, a private vulnerability reporting process (email + required report details), response and coordination expectations with target timelines by severity, a coordinated-disclosure policy (30–90 days), and an acknowledgments section. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related issues
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests
Tip 👮 Agentic pre-merge checks are now available in preview!Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.
Please see the documentation for more information. Example: reviews:
pre_merge_checks:
custom_checks:
- name: "Undocumented Breaking Changes"
mode: "warning"
instructions: |
Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).Please share your feedback with us on this Discord post. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (8)
SECURITY.md (8)
47-50: Finish the acknowledgments section and remove the stray line.The sentence is incomplete and there's a dangling "50" line. Complete the sentence and add a placeholder list or link to a "Hall of Fame."
-## 🙏 Acknowledgments - -We would like to thank the following security researchers who have helped keep SplitWiser safe +## 🙏 Acknowledgments + +We would like to thank the following security researchers who have helped keep SplitWiser safe: + +- (Add names/handles here, or link to a CONTRIBUTORS_SECURITY.md “Hall of Fame”)
12-21: Offer GitHub’s private “Report a vulnerability” path and use a dedicated alias.Add the Security tab path (“Report a vulnerability”) for reporters who prefer not to email. Also consider a project alias (e.g., security@your-domain) instead of a personal Gmail to reduce churn and enable shared inbox.
## 🚨 Reporting a Vulnerability @@ -**Please do not report security vulnerabilities through public GitHub issues, discussions, or comments.** +**Please do not report security vulnerabilities through public GitHub issues, discussions, or comments.** +Prefer the private GitHub path when available: Security tab → “Report a vulnerability”. @@ -1. **Email Us:** Please send details to **[[email protected]](mailto:[email protected])**. +1. **Email Us:** Please send details to **[[email protected]](mailto:[email protected])** (or use the GitHub “Report a vulnerability” button). If email is used, multiple maintainers monitor this inbox.
20-27: Strengthen report content and privacy guidance (versions, env, redactions, severity).Ask for version/commit, environment, configs, and redacted logs; advise not to include secrets/PII; optionally request a CVSS estimate.
2. **Describe the Issue:** To help us triage the issue quickly, please include: - - The type of vulnerability (e.g., "SQL Injection", "XSS"). - - The full URL or code component where the vulnerability was found. - - A detailed description of the steps to reproduce the issue. - - Any proof-of-concept code, screenshots, or requests that demonstrate the exploit. - - The potential impact of the vulnerability. + - The affected version/build (release tag) or commit SHA, and environment (OS, browser, runtime). + - The type of vulnerability (e.g., SQL Injection, XSS) and impacted component/URL. + - Clear reproduction steps and expected vs. actual behavior. + - Proof of concept (redact secrets, tokens, cookies, and any PII). + - Relevant, redacted logs/config snippets and mitigation ideas if known. + - Assessed impact and an optional CVSS v3.1/v4.0 vector if you have one. + +> Privacy: Please do not include credentials, access tokens, or personal data in reports. Redact or fabricate any sensitive values.
30-34: Add severity-based SLAs and clarify business-hours caveats.Provide clearer expectations per severity and note weekends/holidays.
**What to Expect:** -- **Within 48 hours:** You will receive an acknowledgment of your report. +- **Within 48 hours (business days):** Acknowledge receipt of your report. - We will work with you to understand and validate the reported issue. - We will keep you informed as we work on a fix and plan its release. - We will notify you when the vulnerability is resolved and will happily credit you for your discovery (unless you wish to remain anonymous). + +### ⏱️ Target timelines by severity +| Severity | Target fix/release window | +|-----------|---------------------------| +| Critical | 7–14 days | +| High | ≤ 30 days | +| Medium | ≤ 60 days | +| Low | ≤ 90 days | + +These are targets, not guarantees; complex issues or upstream dependencies may require coordination.
39-46: Tighten disclosure language and reflect OSS release reality.Replace “deployed” with “released,” mention GH Security Advisories/CVE, and note exceptions (e.g., active exploitation may accelerate disclosure).
We follow a **coordinated disclosure** process: 1. The vulnerability is reported and privately confirmed. 2. A fix is developed and tested. -3. The fix is deployed to all supported versions. -4. A security advisory is published on GitHub, detailing the vulnerability and crediting the researcher. +3. The fix is released in supported versions (patch/minor), with upgrade guidance and any mitigations. +4. A GitHub Security Advisory (GHSA) is published; we will request a CVE ID via GitHub where appropriate and credit the reporter (or keep anonymous on request). @@ -This process typically takes **30-90 days** from report to public disclosure to ensure users are protected while a fix is developed. +This process typically takes **30–90 days** from report to public disclosure. We may accelerate disclosure for actively exploited issues or extend timelines when coordination with upstream/downstream projects is required.
12-16: Add Safe Harbor and testing boundaries (no DoS/PII/social engineering).Include legal safe-harbor language and clear “do not” testing guidance to protect both maintainers and researchers.
## 🚨 Reporting a Vulnerability @@ The security and privacy of our users are our highest priority. We encourage you to report any potential vulnerabilities directly and privately to our maintainers. +### ✅ Safe Harbor +If you make a good-faith effort to comply with this policy while researching and reporting, we will not pursue or support legal action against you. This includes accidental privacy violations or service disruptions that are promptly reported and minimized. + +### 🔬 Testing Guidelines +- Do not perform denial-of-service, spam, or brute-force attacks. +- Do not access, modify, or exfiltrate data that does not belong to you. +- No social engineering, phishing, or physical attacks. +- Respect rate limits; use test accounts and sample data where possible. + +### Out of Scope (examples) +- Reports without a clear security impact (e.g., descriptive error messages). +- Clickjacking on pages with no sensitive actions. +- SPF/DMARC/DKIM configuration suggestions without exploitability. +- Use of outdated libraries without a proven exploit path.
20-21: Optionally provide a PGP key for encrypted reports.If you keep email, publish a PGP key to allow encrypted reports.
-1. **Email Us:** Please send details to **[[email protected]](mailto:[email protected])**. +1. **Email Us:** Please send details to **[[email protected]](mailto:[email protected])**. For encryption, use our PGP key (fingerprint and block below). + +<details> +<summary>PGP Public Key</summary> + +``` +-----BEGIN PGP PUBLIC KEY BLOCK----- +(add key here) +-----END PGP PUBLIC KEY BLOCK----- +``` +</details>
7-11: Nit: Emoji codes vs. unicode and accessibility.GitHub renders both, but consider using plain text or unicode (✅/❌) and add alt text for screen readers.
-| 1.0.x | :white_check_mark: | -| < 1.0 | :x: | +| 1.0.x | ✅ Supported | +| < 1.0 | ❌ Not supported |
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
SECURITY.md(1 hunks)
🔇 Additional comments (1)
SECURITY.md (1)
7-11: Confirm supported versions reflect actual releases and add explicit EOL datesEnsure the SECURITY.md table maps to real release tags; if 1.0.x is not an actual released tag, replace it with concrete version numbers and add support/EOL dates to avoid confusing reporters.
File: SECURITY.md (lines 7–11). Verify with: git tag -l | sort -V && gh release list --limit 20
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (7)
SECURITY.md (7)
41-41: Clarify response-time wording.“Within 48 hours (business days)” is ambiguous; use “within 2 business days.”
-- **Within 48 hours (business days):** Acknowledge receipt of your report. +- **Within 2 business days:** We will acknowledge receipt of your report.
29-37: Add GitHub Private Reporting as the primary channel; keep email as fallback.Using a personal Gmail is fragile and may miss reports. Prefer GitHub’s built‑in “Report a vulnerability” flow; retain email as backup.
-**How to Report:** - -1. **Email Us:** Please send details to **[[email protected]](mailto:[email protected])**. -2. **Describe the Issue:** To help us triage the issue quickly, please include: +**How to Report (Private):** + +1. **Use GitHub Private Vulnerability Reporting (preferred):** From the repository page, click **Security → Report a vulnerability** and submit your report. +2. **Email (fallback):** If you can’t use GitHub, email **[[email protected]](mailto:[email protected])**. +3. **Provide Details:** To help us triage quickly, please include: - The type of vulnerability (e.g., "SQL Injection", "XSS"). - The full URL or code component where the vulnerability was found. - A detailed description of the steps to reproduce the issue. - Any proof-of-concept code, screenshots, or requests that demonstrate the exploit. - The potential impact of the vulnerability.Please confirm the email is actively monitored and consider setting up a project alias (e.g., security@) and enabling “Private vulnerability reporting” in repo settings.
14-22: Reference a standard Safe Harbor and expand testing boundaries.Link to disclose.io’s policy and call out production‑safety constraints.
-### ✅ Safe Harbor -If you make a good-faith effort to comply with this policy while researching and reporting, we will not pursue or support legal action against you. This includes accidental privacy violations or service disruptions that are promptly reported and minimized. +### ✅ Safe Harbor +If you act in good faith and follow this policy, we will not pursue or support legal action. This includes accidental privacy violations or service disruptions that are promptly reported and minimized. Our intent aligns with the spirit of the [disclose.io Safe Harbor](https://disclose.io/). + +Scope and constraints: +- Do not intentionally access, modify, or exfiltrate data that is not yours; use test data/accounts. +- Avoid actions that degrade availability or quality of service. +- Stop testing and report immediately if you encounter personal data or sensitive information.
23-28: Broaden Out‑of‑Scope to reduce noise.Add common non‑exploitable findings to set clearer expectations.
### Out of Scope (examples) - Reports without a clear security impact (e.g., descriptive error messages). - Clickjacking on pages with no sensitive actions. - SPF/DMARC/DKIM configuration suggestions without exploitability. - Use of outdated libraries without a proven exploit path. + - Self‑XSS (reflected back only to the reporting user). + - Missing security headers without a demonstrated exploit path. + - Best‑practice recommendations only (e.g., 2FA requirement suggestions) without impact. + - Rate‑limit recommendations without demonstrated abuse.
60-67: Tighten coordinated disclosure language.Explicitly request non‑disclosure until a fix is available and define the window.
-We follow a **coordinated disclosure** process: +We follow a **coordinated disclosure** process. Please do not publicly disclose details of the vulnerability until we release a fix and publish an advisory. Our typical process: @@ -This process typically takes **30-90 days** from report to public disclosure to ensure users are protected while a fix is developed. +This process typically takes **30–90 days** from report to public disclosure. If a fix requires more time, we will coordinate an extension with you.
46-55: State how severity is determined (CVSS).Add a note on severity assessment to align expectations.
Note: These are targets, not guarantees; complex issues or upstream dependencies may require coordination. + +Severity is assessed during triage using CVSS v3.1 base scores (or later). We may adjust timelines based on exploitability and impact.
70-71: Finish the Acknowledgments section.Sentence is incomplete and lacks criteria/process for credit.
-We would like to thank the following security researchers who have helped keep SplitWiser safe +We would like to thank security researchers who help keep SplitWiser safe. + +If you’d like recognition, let us know how to credit you (name, handle, link). We maintain a Hall of Fame in this section and in release notes for security fixes.
| +| 1.0.x | ✅ Supported | | ||
| +| < 1.0 | ❌ Not supported | |
There was a problem hiding this comment.
Fix table formatting for Supported Versions.
Lines include leading "+" and lack a header row, so GitHub won’t render a table.
Apply:
-+| 1.0.x | ✅ Supported |
-+| < 1.0 | ❌ Not supported |
+| Version | Support |
+|--------:|:---------|
+| 1.0.x | ✅ Supported |
+| < 1.0 | ❌ Not supported |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| +| 1.0.x | ✅ Supported | | |
| +| < 1.0 | ❌ Not supported | | |
| | Version | Support | | |
| |--------:|:---------| | |
| | 1.0.x | ✅ Supported | | |
| | < 1.0 | ❌ Not supported | |
🤖 Prompt for AI Agents
In SECURITY.md around lines 7 to 8, the table rows include leading "+"
characters and there's no header row so GitHub won't render it as a Markdown
table; remove the leading "+" from the rows and add a header line and a
separator line (e.g., "Supported Version | Status" then "--- | ---") above the
existing rows so the two lines become proper table body rows.
| - +### ⏱️ Target timelines by severity | ||
| +| Severity | Target fix/release window | | ||
| +|-----------|---------------------------| | ||
| +| Critical | 7–14 days | | ||
| +| High | ≤ 30 days | | ||
| +| Medium | ≤ 60 days | | ||
| +| Low | ≤ 90 days | | ||
|
|
||
| +These are targets, not guarantees; complex issues or upstream dependencies may require coordination. | ||
|
|
There was a problem hiding this comment.
Remove diff artifacts and fix the “Target timelines” section rendering.
The header is prefixed with "- +" and the table rows have "+", breaking Markdown.
Apply:
-- +### ⏱️ Target timelines by severity
-+| Severity | Target fix/release window |
-+|-----------|---------------------------|
-+| Critical | 7–14 days |
-+| High | ≤ 30 days |
-+| Medium | ≤ 60 days |
-+| Low | ≤ 90 days |
-
-+These are targets, not guarantees; complex issues or upstream dependencies may require coordination.
+### ⏱️ Target timelines by severity
+| Severity | Target fix/release window |
+|---------|----------------------------|
+| Critical | 7–14 days |
+| High | ≤ 30 days |
+| Medium | ≤ 60 days |
+| Low | ≤ 90 days |
+
+Note: These are targets, not guarantees; complex issues or upstream dependencies may require coordination.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - +### ⏱️ Target timelines by severity | |
| +| Severity | Target fix/release window | | |
| +|-----------|---------------------------| | |
| +| Critical | 7–14 days | | |
| +| High | ≤ 30 days | | |
| +| Medium | ≤ 60 days | | |
| +| Low | ≤ 90 days | | |
| +These are targets, not guarantees; complex issues or upstream dependencies may require coordination. | |
| ### ⏱️ Target timelines by severity | |
| | Severity | Target fix/release window | | |
| |---------|----------------------------| | |
| | Critical | 7–14 days | | |
| | High | ≤ 30 days | | |
| | Medium | ≤ 60 days | | |
| | Low | ≤ 90 days | | |
| Note: These are targets, not guarantees; complex issues or upstream dependencies may require coordination. |
🤖 Prompt for AI Agents
In SECURITY.md around lines 46 to 55, remove leftover diff artifacts (leading
"-" and "+" characters) and correct the “Target timelines by severity” section
so it renders as a proper Markdown subsection followed by a clean table: replace
the garbled header and prefixed table rows with a normal header line (e.g., "###
⏱️ Target timelines by severity") and the four table rows without any "+"
prefixes, and ensure the explanatory sentence below the table is plain text (no
"+" prefixes) so the section renders correctly.
|
Hi @Devasy23 , |
1 participant
This PR adds a
SECURITY.mdfile to provide clear guidelines for reporting security vulnerabilities.Why this is important:
The content provides a template for supported versions, reporting instructions, and what to expect, using the maintainer's email already present in the repository.
Summary by CodeRabbit